Communication sessions, also commonly referred to as “connections,” may exist at different layers of a communications protocol stack, such as the communications protocol stack illustrated in FIG. 1. A communication session, or connection, is a semi-permanent interactive information exchange between two or more communicating nodes, or between a computer and user, that is set up or established at a certain point in time and torn down at a later point in time.
A communication session/connection typically involves the exchange of more than one message in either direction, and a communication session/connection may be stateful, meaning that at least one of the communicating parties needs to save information about the session history in order to be able to communicate. Some stateless protocols may support stateful operations using various mechanisms. For example, the HTTP cookie is a widely used mechanism for a web browser to track and exchange previous activities.
The Internet Engineering Task Force (IETF) Constrained RESTful Environments (CoRE) Working Group (IETF CoRE) has developed Constrained Application Protocol (CoAP). CoAP is a web transfer protocol for use with constrained (e.g., low-power, lossy) nodes and constrained networks.
The interaction model of CoAP is similar to the client/server model of Hypertext Transfer Protocol (HTTP). CoAP uses a two-layer approach, as shown in FIG. 2: a CoAP messaging layer for handling UDP and the asynchronous nature of the interactions; and a request/response interactions layer that uses Methods and Response codes. Current Methods include GET, PUT, POST, and DELETE.
CoAP defines four types of messages: CON, NON, ACK, and RST. A Confirmable message (CON) is retransmitted using a default timeout and exponential back-off between retransmissions until the recipient sends an Acknowledgement message (ACK) with the same Message ID. FIG. 3 shows an example of a CON with ACK of the same Message ID 0x7d34. A Non-confirmable message (NON) does not require reliable transmission. For example, each single measurement out of a stream of sensor data can be sent as a Non-confirmable message. NONs are not acknowledged, but still have a Message ID for duplicate detection. An example of a NON with Message ID 0x01a0 is shown in FIG. 4. An ACK is used to acknowledge receipt of the CON, and a Reset message (RST) may be used when a recipient is not able to process a NON.
CoAP request and response semantics are carried in CoAP messages, which include either a Method code or Response code, respectively. Optional or default request and response information, such as the URI and payload media type, is carried as CoAP Options. A Token is used to match responses to requests independently from the underlying messages.
A request is carried in a CON or NON, and if immediately available, the response to a request carried in a CON is carried in the resulting ACK. This is called a piggy-backed response, as shown in FIG. 5. If a request is sent in a NON, then the response is sent using a new NON.
CoAP messages are encoded in a simple binary format, shown in FIG. 6. The message format starts with a fixed-size 4-byte header, which includes Version, Type, Token Length, Code, and Message ID fields. This header is followed by a variable-length Token value which can be 0-8 bytes long. Following the Token value is a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that occupies the rest of the datagram.
Version (Ver) is a 2-bit unsigned integer that indicates the CoAP version number.
Type (T) is a 2-bit unsigned integer that indicates if this message is of type CON (0), NON (1), ACK (2) or RST (3).
Token Length (TKL) is a 4-bit unsigned integer that indicates the length of the variable-length Token field, which ranges from 0-8 bytes. Lengths 9-15 are reserved, must not be sent, and must be processed as a message format error.
Code is an 8-bit unsigned integer that is split into a 3-bit class (c) and a 5-bit detail (dd) wherein the class comprises the most significant bits and the detail comprises the least significant bits. Code is documented as c.dd, where c is a digit from 0-7 for the 3-bit subfield, and dd are two digits from 00-31 for the 5-bit subfield. The class can indicate a request (0), a success response (2), a client error response (4), or a server error response (5). All other class values are reserved. As a special case, Code 0.00 indicates an empty message. In the case of a request, the Code field indicates the Request Method, and in the case of a response, it indicates a Response Code. The CoAP code registry is as follows: 0.00 indicates an empty message; 0.01-0.31 indicates a request, and values in this range are assigned by the “CoAP Method Codes” sub-registry; 1.00-1.31 is reserved; 2.00-5.31 indicates a response, and values in this range are assigned by the “CoAP Response Codes” sub-registry; and 6.00-7.31 is reserved.
Message ID is a 16-bit unsigned integer in network byte order. The Message ID is used for the detection of message duplication, and to match messages of type ACK/RST to messages of type CON/NON.
Token is a variable length field and may range from 0-8 bytes, as indicated by the Token Length field. The Token value is used to correlate requests and responses.
The Options field allows for the inclusion of CoAP Options and may be followed by the end of the message, by another Option, or by the Payload Marker and the payload, as discussed below.
CoAP defines a number of options which may be included in a message. Each Option instance in a message specifies the Option Number of the defined CoAP Option, the length of the Option Value, and the Option Value itself. Option Value can be empty, opaque, an unsigned integer, or a string. Both requests and responses may include a list of one or more Options. CoAP defines a single set of Options that are used in both requests and responses.
Options are either “critical” or “elective”. An Option is identified by an Option Number, which also provides some additional semantics information. For example, odd numbers indicate a critical Option, while even numbers indicate an elective Option. The difference between these is how an Option unrecognized by an endpoint is handled. Upon reception, unrecognized Options of class “elective” must be silently ignored. Unrecognized Options of class “critical” that occur in a CON request must cause the return of a 4.02, Bad Option, response. Unrecognized Options of class “critical” that occur in a CON response, or piggy-backed in an ACK, must cause the response to be rejected. Unrecognized Options of class “critical” that occur in a NON must cause the message to be rejected.
Options are also classified based on how a proxy is to deal with the Option if the proxy does not recognize it. For this purpose, an Option can either be considered Unsafe-to-Forward, in which UnSafe is set, or Safe-to-Forward, in which UnSafe is not set. In addition, for an Option that is marked Safe-to-Forward, the Option Number indicates whether or not it is intended to be part of the Cache-Key in a request. If some of the NoCacheKey bits are 0, the Option is part of the Cache-Key, and if all NoCacheKey bits are 1, the Option is not part of the Cache-Key. An Option that is repeatable may be included one or more times in a message.
Table 1 displays the properties of CoAP Options using two examples defined in the current CoAP specification: Proxy-scheme and Size1.
TABLE 1Properties of OptionsNo.CUNRNumberCriticalUnsafeNoCacheKeyRepeatableNameFormatLengthDefault39xx—Proxy-String1-255(none)scheme60xSize1Uint0-4 (none)
The CoAP Options are maintained by an Internet Assigned Numbers Authority (IANA) registry. The IANA policy for future additions to this sub-registry is split into three tiers. The range 0-255 is reserved for Options defined by the IETF, range 256-2047 is reserved for commonly used Options with public specifications, and range 2048-64999 is for all other Options, including private or vendor-specific Options.
CoAP defines four methods, GET, POST, PUT and DELETE.
The GET method retrieves a representation for the information that currently corresponds to the resource identified by the request URI. Upon success, a 2.05 (Content) or 2.03 (Valid) response code should be present in the response.
The POST method requests that the representation enclosed in the request be processed. The actual function performed by the POST method is determined by the origin server and dependent on the target resource. POST usually results in the creation of a new resource or updating of the target resource.
The PUT method requests that the resource identified by the request URI be updated or created with the enclosed representation. If a resource exists at the request URI, the enclosed representation should be considered a modified version of that resource, and a 2.04 (Changed) response code should be returned. If no resource exists, then the server may create a new resource with that URI, resulting in a 2.01 (Created) response code.
The DELETE method requests that the resource identified by the request URI be deleted.
CoAP also allows the use of proxies. A forward-proxy is explicitly selected by a client and acts on behalf of the client. To the server, the request from the proxy is as if coming from the client. All Options selected in a message to a forward-proxy request must be processed at the proxy. CoAP distinguishes between requests made to an origin server and a request made through a forward-proxy. A reverse-proxy is inserted to stand in for origin servers. To the client, the response from the proxy is as if coming from the server. A reverse-proxy may or may not interpret the request.
CoAP core protocol is Request-Response based and does not work well when a client is interested in having the resource representation over a period of time. CoAP Observe extends the CoAP core protocol with a mechanism for a CoAP client to “observe” a resource on a CoAP server. The client can retrieve a representation of the resource and request this representation be updated by the server as long as the client is interested in the resource. Observe is a subscribe-notification mechanism for one Request to get multiple Responses. It can be viewed as a form of session, for the purpose of notifications, as illustrated in FIG. 7
The CoAP base protocol defines that CoAP can be provisioned in “NoSec” mode, meaning without using Datagram Transport Layer Security (DTLS), or it can be provisioned using DTLS for security. The DTLS protocol is designed to secure data between communicating applications. DTLS is largely based on Transport Layer Security (TLS), but DTLS operates over UDP and is used for UDP or other connectionless based protocols. Datagram transport such as UDP does not require or provide reliable or in-order delivery of data. The DTLS protocol provides such in-order delivery for payload data by using a sequence number. To initiate a connection session, DTLS supports a handshake protocol, which opens the session, and each session has a session identifier. DTLS explicitly uses a sequence number for DTLS records, which are encapsulated data to be exchanged via the connection session. To utilize DTLS, the node acting as the CoAP client should also act as the DTLS client.
The WebSocket protocol is designed to provide full-duplex communications channels for web browsers and web servers over a single TCP connection. A bi-directional ongoing conversation can take place between a browser and server without needing to open multiple HTTP connections or performing long polling as was required in the past. WebSocket provides a standardized way for a server to send content to a browser without being solicited by the client. It allows messages to be passed back and forth while keeping the connection open and enables live content and the creation of real-time games.
WebSocket utilizes an opening handshake followed by basic messaging layered over TCP using TCP port number 80, the same port that HTTP uses. Using this port provides the advantage that WebSocket traffic can pass through most existing firewalls. The only relationship WebSocket has to HTTP is the opening handshake used to establish a connection. The handshake is formatted as an HTTP upgrade request so that HTTP servers are able to recognize it and WebSocket can then use port 80. Once a WebSocket connection is established, data frames are exchanged. FIG. 8 illustrates basic WebSocket procedures.
The IETF CoRE received a proposal for a CoAP over WebSocket protocol. CoAP over WebSocket addresses the environment where UDP transport is not available. One such example is a corporate network where Internet access is only available via an HTTP proxy. Another such example is a CoAP application running in a web browser which has access only to HTTP and WebSocket. The protocol's layer diagram is shown in FIG. 9. Note that CoAP over WebSocket involves HTTP and TCP.
CoAP over WebSocket begins with an opening handshake. To accomplish this, a WebSocket Connection needs to be established in accordance with RFC6455, and the WebSocket client must include “coap.v1” as its sub-protocol name. After the opening handshake, CoAP requests and responses are exchanged as WebSocket messages. Messages are transmitted in binary data frames because CoAP uses a binary message format. The CoAP requests and responses are exchanged asynchronously over the WebSocket Connection. The process of closing the CoAP over WebSocket connection is identical to that of the traditional WebSocket protocol, as found in RFC6455.